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L IntrDductioa 

In response to the Office Acrion dated February 8, 2005, which wjas made final, claims 1, 6, 
8, 12, 17, 19, 23, 28, 30 and 34 have been amended, and new claims 41-50 have been added. C3flims 
1-4, 6, 8-10, 12-15, 17, 19-21, 23-26, 28, 30-32, 34-39 and 41-50 are in the application. Entry of 
these amendments, and te-congideration of the application, as amended, is requested, 

n. Interview Summaiy Recoid 

Record is made of telephonic interviews that occurred on March 23, 2005 and April 7, 2005 
between Ejcaminer Nalven and the below-signed attorney Possible claim amendments were 
discussed, along with the prior art references, but no agreement was reached, 

III. PriprAiftRejeqtiQm 

A. The Office Action Rejections 

In paragraphs (3)-(4) of the Office Acdon, claims 1-3, 6, 8-10, 12-14, 17, 19^21, 23-25, 28, 
30-32, 34, and 36-38 were rejected under 35 U5.C §103(a) as being unpatentable over Hunt, US, 
Patent No. 6,154747 (Hunt) in view of Fischer, US. Patent No. 6,105,072 (Fischer) and funher in 
view of Morel et al., U5. Patent No, 5,721,919 (Morel). In paragraph (7) of the Office Acrion, 
claims 4, 15, 26, 35, and 39 were rejected under 35 US.G §103(a) as being unpatentable over Hiinr, 
Fischer, and Morel as applied to claims 1, 23, and 34, and further in view of Moore, US. Patent No. 
5,343,527 (Mooie). 

Applicants' attomey respectfully traverses these rejccrions. 

B. The Applicants* Indepen<|f fT^ Hafm^ 

Independent claims 1, 12 and 23 are generally directed to checking a version of an abstract 
data type stored in a database. Independent claim 1 is representative, and comprises: 

(a) constructing an identifier for the abstract data type, wherein the identifier comprises a 
concatenation of information describing the abstract data type that is substantially umque to the 
abstract data type; 

(b) hashir^ the constructed identifier to generate a signature hash vabe for the abstract data 

type; 
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(c) storir^ the signature hash value in the database and a dass definition for the abstract data 
type; and 

(cQ comparing the signature hash value from the database Twrh the signature hash vahie from 
the class definirion after the class definition is instantiated in oxder to verify that the class def inirion 
is not outdated. 

Independent ^h'^rry^ 6, 17 and 28 are generally directed to generating a signature hash value 
for checking a version of an abstract data type stored in databases. Independent claim 6 is 
representative, and comprises: 

(a) constructing an identifier for the abstract data type, wherein the identifier comprises a 
concatenation of information describing the abstract data type that is substantially unique to the 
abstract data type; 

(b) h as ^^'T^ g the constnicted identifier to generate a signature hash value for the abstract data 
type; and 

(c) storir^ the signature hash value in the database and a class for the abstract data type. 
Independent claims 8, 19 and 30 are generally directed to verifying a signature hash vahie for 

checking a version of an abstract data type stored m a database. Independent claim 8 is 
representative, and comprises: 

(a) accessing a first signature hash value from the database and a second signature hash value 
from a class definition for the abstract data type, wherein the first and second signature hash values 
have been constmcted from an identifier for the abstract data, type, the identifier corrprises a 
concatenation of informatiDn describing the abstract data type that is substantially unique to the 
abstract data type, and the identifier has been hashed to generate the first and second stature hash 
values; and 

(b) comparing the first signature hash value widi the second signature hash value after the 
class definirion is instantiated in order to verify that the class definition is not outdated- 
Independent claim 34 is directed to at least one data structure stored in a memory for use in 

checking a version of an abstract data type stored in a database, the data structure comprisir^ a 
signature hash value for the abstract data type generated from an identifier constructed for the 
abstract data type, wherein the identifier coinprises a concatenation of informarion describing the 
abstract data type that is substantially unique to the abstract data type and the identifier is hashed to 
generate the signature hash value for the abstract data type. 

.11. 

G&C 30571.23 l-US-Ul 

PAGE14/23'RCVDATm054:46:58PM [Eastern Dayp 



04-08-2005 01 :03PM * FROM-Gates i Cooper LLP 



+13106418798 



T-451 P. 015/023 F-810 



C Hie Hunt Reference 

Hunt describes a method using a plurality of hash tables to provide an object reposiroiy for 
object oriented applicatbn development and use. The noethod includes storing an object identifier 
and a representation of the object in a fiist hash table and storing dau about the object and the 
object identifier in a plurality of paired hash tables with the hash tables organized in mirrored table 
pahs. The data about the object include an object's class name, object methods, return types, and the 
data values returned by object methods. The non-inveise hash tables of the mirrored table pairs 
suppoiT fuzzy searches for objects -while the mverse hash tables of the mirrored table pairs support 
searches for objects by object identifier. A system that implernents the invenrive method includes a 
first hash table for storage of data representing the object with an object identifier used as a key for 
storage of the representing data and a plurality of mirrored table pairs for the storage of data about 
objects. In the non-inverse table of the mirrored table pairs, the data about the objects are used as 
keys to store an object identifier. In the inverse tables of the mirrored table pairs, the object 
identifier is used as the tey for storage of the data about the data objects. The mirrored table pairs 
and hash table provide an efficient and economical object repository. Such an objea repository may 
be provided vrith a computer application at a nominal eaqjense. Thus, object oriented applications 
maybe devebped -without regard for "whether the end xjscr system incbdes an object repository. 

D. The Fischer Reference 

Fischer describes a method of operating computers in accordance ^with an enhanced object- 
oriented programming methodobgy that creates a framework for efficiently performir^ automated 
business transactions. The object-oriented programming methodology is used in conjunction with a 
travelling program, Le., a digital data structure which includes a sequence of instructiotis and 
associated data which has the capability of determinir^ at least one next destination or recipient for 
receiving the travelUng program and for transmitting itself, together with all relevant data determined 
by the program to the next recipient or destination Using the methods described herein, the data is 
more cbsely bound to the program in such a way that objects maybe most efGciendy transferred 
from one computer user to another without the objects being previously known to the recipient 
computer user The present invention utilizes object "cells*' which are data stmctures stored, for 
example, on a disk that reflects a collection of (related) objects instances whose execution has been 
suspended, and which can be resumed later on the same or a different platform. The collection of 
object instances can be gathered together into ceDs (or "elearonic forms*) suitable for storage or 
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iransmission to another con^ter user in such a way that instances are iinambiguousfy' bound to 
their respective class definition. The present invention also creates impioved tools for creating and 
using celk so that electronic forms can be defined usii^ object-onenred techniques while allowing 
such forms to be easily transferred among a diverse population of computer users- without 
demandii^ that all useis maintain compatible libraries of all object-class definition programs and 
without demanding that all usets maintain identical synchronized versions of that class. The 
invention provides a digoal signature methodology to insure security and integzity, so that electronic 
forms (le., cells) composed of a collection of objects can be received and executed by a user without 
pmdng the user at risk that some of the object classes embedded in the cell might be subversive 
"trojan horse" programs that m^t steal, destroy or otherwise compromise the security or integrity 
of the user's system or data, 

E. The Morel Reference 

Morel describes a method and system for tracfcmg, and resolving links to, objects that derive 
from a common object creation. In a system, the system creates a source object. The system then 
generates a lineage identifier to identify the creation of the source object Then the system associates 
the lineage identifier with the source object. At a later time, the system copies the created object to a 
copy object. When the source object is copied to a copy object, the system associates the lineage 
identifier associated with the source object with the copy object. In this way, the lineage identifier 
associated with the copy object mdicates that the copy object derives from the creation of the source 
object. The system links a client object to a source object by storing a li'nlc containing the source 
objea^s lineage identifier in the client object, A link also contains information for di^ngiTishing the 
source object from other objects having the same lineage identifier. When resolving the link to the 
source object, the system selects the lineage identifier ^ nd the dKtin guiQtiing information contained 
in the link The system then searches for an object with the selected lineage identifier and 
distinguishing inf onnation. When an object with the selected lineage identifier and distir^^hii^ 
information is found, the system resolves the link to the found object. When an object with the 
selected lineage identifier and distinguishing information is not foxmd, the system searches for an 
objea with the selected lineage identifier without regard to the selected distir^;uishing information, 
When an object with the selected lineage identifier is found, the system resolves the link to this 
found object, 
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F. The Moore Refei^nce 

Moorc describes a system and method for providing a reuser of a software reuse libraiy with 
an indkaiion of whether or not a software component from the reuse library is auriientic and 
whether or not the software component has been modified The system and medaod discbsed 
provides a leuser whh assurance that the software component retrieved was placed in the reuse 
library by the original publisher and has not modified by a third pany. The system and method 
disclosed uses a hybrid cryptographic technique that combines a conventional or private key 
algorithm with a public key algorithm. 

G. Thg A pplicants' Haims An^ Patentable Over The Reference 

Apphcants' invention, as recited in the claims, is patentable over the references, because the 
claims recite limitations not found in the references. 

On the other hand, the Office Actbn asserts that Hunt teaches the construction of an 
identifier for the abstract data type where the identifier is substantially unique to the data type and 
the identifier comprises a concatenation of various attributes for the data type, at column 6, lines 43- 
45, column 6, lines 45-50, column 7, lines 1-3 and column 7, lines 42-49, 

However, at the cited locations, Himt merely discloses the following: 

Hunt, column 6. lines 43-50 factually^ lines 29-67) 
A preferred structure for objea repository 1 8 that may be accessed by an 
instance of the gateway depicted in HG. 3 is shown in FIG. 4- Object repository 18 
includes a single hash table 62 and hash table pairs 64, 68, 72, and 74 which are 
organized in mirrored table pairs. Each mirrored table pair is comprised of a non- 
inverse hash table and an inverse hash table. Hie inverse tables are so referenced 
because they reverse the key/value organization of the noiirinverse hash tables. 
Mrrored table pair 64 stores class names for objects. Moirored table pair 68 stores 
data regarding the n^thods used by the objects stored in repository 18 aiid mirrored 
table pair 72 stores data regarding return types for the methods of the objects stored 
in repository 18. Mirrored table pair 74 is used to store data values returned by the 
methods for objects stored in repository 18, Hash table 62 is organized to stoie 
object data using an object identtfier as a key. Preferably, the database used to 
implement the hash tables of repository 18 generate the key for storing information 
in a hash table by providing an object identSier (OID) as an argument to a hashing 
function. The value generated by the hashing function is used as a key for storing 
data in a hash table. Because use of serialized data object data would not be 
efficiently hashed to generate a key, the hash table used to store object data does not 
have a corresponding inverse table. Instead, an OID is used as a key to store object 
data in hash table 62 after the object data has been serialized, that is, converted to 
string data. An object's class name is stored in the non-inverse table 64a as the key 
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for the OID of die corresponding data object Likewise, object methods are stored 
in nonrinverse table 68a as die k^for die Off) of die corresponding object and the 
return types for die mediods of the objects arc stored in the non-invetse table 72a as 
the key for the OID of the coiresponding object. Ihe data value returned by a 
method of an object is concatenated with the object's dass nanoe and method to 
generate a key that is used to store the OID in non-inverse tabic 74a. In the inverse 
table of each of the mirrored table pairs, the OID is used as the key to store the data 
value that is the key for the OID in the non-inveise table, 

'Hunt, cQtumn 7, lines 1-^ (^^^^ %t li^^^ ^-^^^ 

Preferably, each hash table of objea repository 18 is implemented with a 
Berkeley DB database system available from Sleepycat Software Inc, of Carlisle, 
Mass. and the programming language statements that implement instances of 
interface 20 comraunicate widi dhe management system for the Berkeley DB through 
a thread extending to repository 18. Hie Berkeley DB database uses imion data 
stmctuies implemented in the C programming language. Preferably, one Berkeley 
DB is used for each of the nm^ hash tables required to implement the preferred 
structure discussed above. Eight of the Berkeley DBs are used for the four mirrored 
table pairs and the other BerteleyDB is used for the sii^ hash table in the 
preferred in^lementation. Berkeley DBs maybe configured for one of three access 
Ecethods. These access methods arc binary tree (mode 1), exrended linear hash table 
(mode 2), and fixed or variable length record (mode 3). Preferably> the Berkeley 
databases are configured to operate in mode 2 for use as hash tables. The 
progiammit^ statements that implement interface 20 preferably inchide five (5) 
instances of a Java class with four of the five class instrances controlling access to a 
mirrored table pair and the fifth instance of the class controlling access to the single 
hash table. The Berkeley DB preferably used to implement repository 18 also 
includes a management system that handbs transactions, loddr^ logging, shared 
memory caching and database recovery In addition, Berkeley DB supports Q C++, 
Java and Perl applicadon programming interfaces. 

Hunt, column 7. lines 42-49 factu ally^ Imf < 

Object identifiers are preferably generated by capturing system time in 
milliseconds since a certain dare in 1970 and concatei^tir^ that value with the 
number of objects processed by the instance of interface 20 being used by an 
application 14. This object ideritifier (OID) is preferably generated in string form and 
is returned to application programs 14 as well as being used to store data in objea 
reposlroiy 18. However, in distributed environments, two instances of interface 20 
rmy have processed the same number of data objects and may generate an object 
Identifier at the same time. Accordingly, both instances would generate the same 
object identifier. As a resuk, the object identifier maybe provided to the wrong 
instance of interface 20 for retrieval of the object without detection or an atten^t to 
store different objects in the same repository with the same OID may occur. To 
reduce the likelihood of this occurrence, generation of the OID is performed as 
discussed above except a prefbc string corresponding to the name of the server on 
■^rfiich an instance of interface 20 is executing is concatenated to the OJD. As 
instances of interface 20 likely execute on different servers in a distributed 
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eavironnient, this method of ODD generation addresses the j:ismote likelihood of the 
same OID being generated by different instances of interface 20, 

The above poitions of Hunt merely state that the object identifier (OID) is geneiated by 
capturing system rime in milliseconds since a certain date in 1970, concatenating that value with the 
number of objects processed by the instance of interface 20 being used by an application 14, and 
prefixing a string corresponding to the name of the server on Tvhich an instance of interface 20 is 
executing. However, Hunt does not teach or suggest constructing an identifier from a 
concatenation of information describing an abstract data type that is substantially unique to the 
abstract data type. Specifically, the system time, number of objects processed, and name of the 
server do not comprise "information describir^ the abstract data type.*" 

The Office Action also asserts that Morel teaches the storing of the hash value in the class 
definition, at column 8, lines 57-63 and column 3, lines 33-62. 

However, at the dted locations, Morel merely discloses the following: 

Morel, column 8. lines 57-63 (acmanv, column 8. line 51 - column 9> line 2) 
^Klien the facility generates an object identifier including a lineage identifier 
and a distinguished identifier) for an object, it associates that object identifier with 
the object so that (a) when a user decides to establish a link to the object, the facility 
can establish a link containing the object identifier, and (b) the facility can search for 
objects having a certain object identifier when resohong the link. In a preferred 
embodiment, when the facility associates an object identifier with an object, it stores 
the object identifier inside the object. In this way, the object knows its own object 
identifier. Hie facilrty preferably establishes an object identifier table that maps 
object identifiers to the pathnames of the associated objects, ^)^hen an object 
identifier is generated for an object, the facility updates the object identifier table to 
include a mapping of that ob^ct identifier to the pathname of the object- If the user 
moves or renames the object, the facility updates the pathname stored in the object 
identifier table* Storing the object ident^ers in a table permits the facility to quickly 
search for objects. 

MoreL colnmn 5> Unes 33-62 

The system links a client object to a source object by storing a link containing 
the source object^s lineage identifier in the diem object. A Imk also contains 
information for distir^pishing the source object from other objects having the same 
lineage identifier. \Phen resolving the link to the source object, the system selects the 
hneage identifier and the distinguishing information contained in the link The 
system then searches for an object with the selected liraea^ identifier and 
distinguishing information. When an object vMi the selected lineage identifier and 
distinguishing information is found, the system resolves the link to the found object. 
When an object with the selected lineage identifier and distinguishing information is 
not found, the system searches for an object with the sdecied line^e identifier 
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withom regard to ihe seleaed distinguishing mformarioru XSWien an object with the 
selected lineage identifier is found, the link system resolves the link to this found 
object. 

^en lesolving a V^v^ the system preferably searches for the source objeci of 
the link in a series of volumes in an optimal order. The system preferabfy first checks 
a pathname stored in the l inK then searches a hinted volume, then searches all local 
volumes, then searches volumes in an automatic volume list, then searches volumes 
in a mgniifll volume list, then searches volumes in remote vohune lists indicated by a 
list of remote volume l^ts, then broadcasts a search request to all connected 
machines. The system preferably also irt^jlements an object identifier table that maps 
from object identifiers used in links directly to file system identifiers, thereby^ 
bypassing the step of looking up a source object file name in a directory specified by 
a pathname. 

The above portions of Morel merely describe a lineage kfentifier for a source object being 
associated widi a copy object to indicate that the copy objea derives from the source object. 
However, Morel does not teach or suggest storing a signature hash vahie both in a database and a 
class definition for the abstract data type, so that at a later time the signature hash value from the 
database can be compared with the signature hash value from the dass definition, after the class 
definition is instantiated, in order to verify that the class definition is not outdated. 

Finally, the Office Action asserts that Fischer teaches the comparing of signature hash values 
from the database -with signature hash values from the class definition, at colinnn 30, lines 24-44 and 
55-58, column 30, line 66 - column 31, line 12, and column 4, lines 19-49. 

However, at tiie cited locations, Fischer merely discbses the following: 

Pischer^column 30._lines 24-44 (a f-tnglly; 1iTif^< '>'v^S^ 

In reloading a class, it is necessary to reestablish the class exacriy as it existed 
before* The reload class routine begins at block 1202 where a newclassBlock is 
created which corresponds to the prospective bad (block will be deleted in case of 
failure), the classBlock is connected to the class list and an indication is made as to 
whether the classBlock is incompletely loaded as previously described to detect 
circular inheritance. 

A check Is made at block 1206 to determine whether class p-code definition 
is already provided in the celL If so, riien the routine branches to block 1230 and 
processes the p-code image as carried in the cell. If the p-code definition is not 
present, then a check is made to determine if the class source code definition is 
provided in the cell If so, then the routine branches to 1220 and processes the 
source image as carried in the celL If neither the p-code not source code is present, 
then the routine proceeds to block 1210 where the class definitbn is indicated by 
program name, program version, by p-code and source hash. The name (and 
possibly the hash) of the class is used to locate (another) local copy of the p-code or 
the source. 
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K<:rher. column 30, linfis 55-58 f ^miglly^ liWg 55^651 

If the soxaice code has been located, then at block 1220, it is compiled and 
the hash of the source is computed If the computed soiirce hash imtches tiiat 
defined in the authenticated aspect of the cell, then the class is accepted. It is 
possibk that the source hash is based not on the exact source, but rather a 
normalized form, for example, with the comments removed and nonessential 
spacing deleted. Thereafter, in block 1220, the class authorization is established 
associated with the source code. Hie source defioition is compiled using whatever 
con^aler is appropriate to the source definition if multiple lai^uages are supported- 

Fischer, column 30. l i'n^ - ^ olumn 31. line 12 

Processing then cominues in block 1232. If the prior processing involved a 
block 1230, then die located version of the p-code is loaded fiom the local file 
repository or within the cell itself. Tie hash of the p-code is computed as it is loaded- 
A check is made to ensure that the precompiled p-code is in a format el^Ue for 
being processed by this interpreter/executor and the class authorization is 
estaUished that is associated with the p-code. A check is made to determine whether 
the coir^uted hash of the p-code equals the eacpected value as defined in the 
authenticated patt of the cell If there is a match, then the class is accepted If not, an 
error indicator is generated. Hie ptocessmg at 1232 additionally saves the hash of the 
original source which is given in p-code, 

Fischer, column 4, lines 19-49 

This provides integrity by insuring that changed "library or template 
versions of a class program cannot inadvertently operate on older instance dataj or 
that other incorrect versions of a class program cannot be inadvertendy used (and 
cause confusion or damage) when a cell is activated at different tinges by a variety of 
users (recipients) [even if one of the users may have a class program with a matching 
name]. The unambiguous binding between instance and class maybe provided in a 
variety of ways includir^: 

by binding an object instance in a cell to its class by including the class 
definition-Le., the class program logic itself, whether it be in source, p-code or 
matching code-as part of the cell data structure- 
By binding an object instance in a cell to its class by including in the cell a 
[cryptographic] HASH of at least one of: the SOURCE instructions (or normalized 
version thereof); the pseudo-code (p-code) instrucrions resulting from cortpilarioi^ 
or the machine language code resulting from conopilarionr-f or the class program 
definm'on. 

The binding correlates to each instance with precisely the correct 
corresponding class program-so that another class with the same name, or an 
anachronistic version (too old or too new) of the class-carmot be inadvertently 
selected to operate on the existing version of instance data, when the cell is reloaded. 
This is especially useful for class programs that perform critical or sensitive 
functions. In this fashion, "master^ class definiuons maybe changed without 
ir[:^>airing or confusing existing instances that depend on the specification of the 
class definrrion at the time the instance was created. 
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The above portbm of Fischer meidy describes how the source code of a class defininon is 
hashed, but this hashing function is performed each time the souice code is located and is not stored 
in the source code. However, Fischer does not teach or suggest storing a signature bash value both 
in a database and a class defininon for the abstract data type, so that at a later time the signature 
hash value from the database can be compared with the signature hash value from the class 
definirion, after the class defininon is instantiated, in order to verify that the class de fi nition is not 
outdated. 

Consequently, even when combined, Hunt, Fischer and Morel do not teach or suggest the 
limitations of Applicants* claimed invention. Moreover, dae various elements of Applicants' claimed 
invention together provide operational advann^es over the references. In addition. Applicants' 
invenuon solves problems not recognized by the references. 

Thus, Applicants* attorney submits that Independent claims 1, 6, 8, 12, 17, 19, 23, 28, 30, and 
34 are allowable over Hum, Fischer and MoreL Further, dependent claims 2-4, 9-10, 13-15, 20-21, 
24-26, 3 1-32, 35-39 and 41-50 are submhxed to be albwable over the references in the same manner, 
because they are dependent on independent claims 1, 6, 8, 12, 17, 19, 23, 28, 30, and 34, respectively, 
and thus contain all the limitations of the independent claims* In addition, dependent claims 2-4, 9- 
10, 13-15, 20-21, 24-26, 31-32, 35-39 and 41-50 recite additbnal novel elements not shown by the 
references. 

IV. qpnclusigr^ 

In view of the above, i: is submitted that this application is now in good order for albwance 
and such allowance is respectfully solicited. 
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Should the Examiner beKeve minor matters still neimiii that can be resolved in a tekphone 
interview, the Examiner is urged to call Applicants* undersigned attorney- 

Respectfully submitted, 

GATES & COOPER LLP 
Attorneys for Applicants 

Hbvrard Hughes Center 

6701 Center Drive West, Suite 1050 

Los Angeles, Qlifomia 90045 

(310)64L8797 

Date: April 8, 2005 ^T^JT^^ 

Nami: Cfe^ige VL Gates 



GHG/ 



G«C30571^X-US-U1 



ige. 

Reg. No.: 33,500 
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